home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX 5.3 for Indy R4400
/
IRIX 5.3 for Indy R4400 175MHz.img
/
relnotes
/
explorer
/
ch4.z
/
ch4
Wrap
Text File
|
1995-02-28
|
24KB
|
661 lines
- 1 -
4. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s
This chapter describes the known problems with release 2.2.2
of IRIS Explorer and, where known, ways to work around them.
4.1 _M_a_p__E_d_i_t_o_r
+o Explorer, because it is a multiprocess application, can
consume a substantial number of processes and file
descriptors, depending on its use.
+o When modules that contain file browser widgets are run
remotely, the widgets show files that are available
only on the local machine. To correctly enter a remote
filename in this case, the name must be correctly typed
into the text field without the benefit of the browsing
capability. All Explorer modules have been modified to
remove the file browser from the control panel, moving
it instead to the module menu bar.
+o The ``Interrupt'' item on module menus interrupts user
functions with the UNIX signal SSSSIIIIGGGGUUUUSSSSRRRR1111. User functions
must not interfere with the capturing of this signal.
Modules that are multithreaded, such as the image
processing modules on multiprocessors, will not
properly clean up the parallel threads when interrupted
with this feature, and may fail on subsequent firings.
+o Modules that have parameter functions on their inputs
cannot be duplicated or copied from the cut buffer
without an error message complaining about can't find
upstream module.
+o The (destroy) and (disconnect) scripting language
commands are not synchronous. Hence, if you re-create
a link or module immediately after destroying it, an
error might occur in the naming of the new item.
+o If you save a portion of a map containing nested loops,
and save both loop controllers but not the entire inner
loop, relaunching that map might cause the incorrect
module to be selected as the loop controller.
+o When running an application with only maximized control
panels visible, selecting the Motif menu ``Close'' item
causes the control panel to go away, but the map
programs continue to run. You must use the shell
command _p_s to find and destroy the processes. Sending
a _k_i_l_l to the process named _g_u_i should suffice. You
should define a ``Quit'' menu bar item to exit the
application, and then use it to exit the application.
- 2 -
4.2 _F_i_r_i_n_g__A_l_g_o_r_i_t_h_m__A_n_o_m_a_l_i_e_s
+o In version 2.1, widget values set programmatically
(e.g. with _c_x_I_n_W_d_g_t_D_b_l_S_e_t) would change the widget, but
would not change the port value if the _F_i_r_e _N_o_w menu
was selected. This has been partially fixed. The
correct value now appears on the port but the values
returned from _c_x_I_n_p_u_t_D_a_t_a_C_h_a_n_g_e_d and
_c_x_I_n_p_u_t_D_a_t_a_C_h_a_n_g_e_d_V may be inconsistent. It is best to
assume that all widget values have changed. Note that
the new widget values set programmatically were never
intended to appear on the port until the next time the
module fires.
+o Button widgets are always marked as ``new data'' when a
module starts execution, even if the initialization
hook function calls _c_x_I_n_p_u_t_D_a_t_a_G_e_t on that port.
+o Nested loops perform correctly in most cases, but
certain loop wirings can cause problems. In
particular, a loop control module cannot receive data
both from within its loop and from within an inner
loop. The data from the inner loop must be wired to
that loop's controller, then on to the outer loop
controller. Routing all data through the inner
controller allows the inner controller to send
consistent control information to the outer loop
controller.
In addition, if an outer controller receives data from
an inner loop, you must route all data going to the
outer controller through the inner controller. Failure
to do so causes the outer controller to receive data at
different loop nesting depths, which it might be unable
to handle.
4.3 _S_h_a_r_e_d__M_e_m_o_r_y__A_n_o_m_a_l_i_e_s
+o If a module dies while allocating shared memory, it
locks the arena memory allocator, preventing other
module operations. This has the appearance of the map
failing to fire after a module has died unexpectedly.
It is best to save your map and restart Explorer when
this happens.
+o When the disk containing the shared memory arena fills
up during the execution of an Explorer map, there might
be no error reported, but the execution of the map
- 3 -
stalls. This condition will often only manifest itself
via system error messages in the console window.
4.4 _M_o_d_u_l_e__S_u_i_t_e
+o Certain modules in Explorer version 2.2 are
incompatible with the dynamic shared objects (DSOs)
_l_i_b_c_x._s_o and _l_i_b_c_x_X._s_o in this release. However, all
such modules are authored by Silicon Graphics, are
included on this release, and are intended to be
installed to replace the previous distribution.
In the event that you fail to replace the old module
during installation of Explorer 2.2.2, that module will
fail to start up the next time it is launched in the
Map Editor. The solution is to install the new module
from the 2.2.2 distribution of Explorer. Affected
modules include _A_n_n_o_t_a_t_i_o_n, _C_l_i_p_P_y_r, _D_i_s_p_l_a_y_I_m_g,
_I_L_C_o_n_t_r_o_l_l_e_r, _I_s_o_s_u_r_f_a_c_e_P_y_r, _S_l_i_c_e_P_y_r, _T_r_i_a_n_g_u_l_a_t_e_2_D,
and _T_r_i_a_n_g_u_l_a_t_e_3_D.
Normally the old DSOs are distributed with each new
release of a system such as Explorer to prevent this
type of problem. But version 2.2 modules using the
version 2.2 _l_i_b_c_x_X._s_o are incompatible with the new
Motif DSO (which is _n_o_t being re-released as an
incompatible upgrade). Therefore, to ship the old
Explorer DSO would allow an old module (including those
written by users) to execute incorrectly. We choose
instead to make obsolete the above modules from version
2.2 and to replace the Explorer 2.2 DSOs with new ones.
With this approach there should be no adverse effects
on any user-written modules.
+o The _R_e_n_d_e_r module puts its menus in the overlay planes
to avoid superfluous redraws. Due to a bug, these menus
may have an incorrect background color such as red or
black on 8-bit or pseudo-color visuals. When the
background color turns black it is the same as the
foreground color and the menu is unreadable.
We have worked around this problem for _R_e_n_d_e_r pull-down
menus, at some cost in re-rendering of scenes, by
taking them out of the overlay planes. However, the
button-3 pop-up menu remains in the overlay planes and
may become unreadable. If so, move the maximized _R_e_n_d_e_r
window around the screen; this seems to help clear up
the popup colormap temporarily. Or, if you have a 24-
bit system, use the TrueColor visual instead.
- 4 -
+o In _R_e_n_d_e_r, Personal IRIS systems support only screen
door transparency.
+o In _R_e_n_d_e_r, two-sided lighting does not work on IRIS
Indigo systems with Entry or XS graphics, even though
the systems have this capability. This problem is
exhibited when the _R_e_n_d_e_r module is run on one system
and displays on a second, using DGL (distributed
graphics library). This problem results in displays
that are completely dark on one side and correctly lit
on the other.
+o In _R_e_n_d_e_r, selecting geometry objects received on the
Screen input port does not always work correctly.
Highlights and manipulators might be placed
incorrectly. The Transform Sliders can be used to
position these objects accurately.
+o The _R_e_n_d_e_r module is sensitive to some X Window System
application defaults. For example, setting
``*borderWidth:2'' causes the module to redraw itself
improperly when its window is resized.
+o The _R_e_n_d_e_r module may print to standard output a terse
message of the form ``id XX not found,'' where XX is an
integer. This sometimes happens during disconnection of
a wire or destruction of a _R_e_n_d_e_r module. No action is
necessary.
+o _R_e_n_d_e_r and other modules that receive geometry slowly
accumulate memory, possibly causing some fragmentation
of memory. The problem is that each Inventor scene
graph node has a name and the small names accumulate in
the process that transcribes in geometry. The names
are now block allocated, so the fragmentation problem
isn't as severe as it was formerly, but it can still
cause problems if the module receives very large
geometries many times. There is no workaround to this
problem, although we have increased the block size of
the names somewhat to push the failure point further
out.
+o Some version 2.1 image processing modules (names end in
_I_m_g) may exit when run in the 2.2.2 Map Editor. Install
the new image processing modules from this
distribution.
+o In _C_o_n_t_o_u_r, taking contours of large volumes with many
slices might consume excessive memory.
- 5 -
+o The _G_e_n_e_r_a_t_e_C_o_l_o_r_m_a_p module does not compute ideal
control points for colormaps given all possible lattice
colormap inputs. In particular, it might not place
control points close enough together if the input
lattice has discontinuities in one or more of the color
channels.
Additionally, it might not pick ideal slopes for
control points even when given smooth inputs.
The module sometimes produces a colormap with zero
opacity, resulting in completely transparent objects.
Refiring the module one or more times often resets the
opacity back to the desired values.
When given input consisting of a step-function
colormap, the module represents the colormap
incorrectly. However, the output colormap is left
unmodified as long as you do not use _G_e_n_e_r_a_t_e_C_o_l_o_r_m_a_p's
colormap editing facilities.
+o The _I_s_o_s_u_r_f_a_c_e_P_y_r module exits abnormally when given
the dataset /_u_s_r/_e_x_p_l_o_r_e_r/_d_a_t_a/_p_y_r_a_m_i_d/_s_h_u_t_t_l_e._p_y_r as
input. The module is unable to accept this form of
compressed input.
+o In _L_a_t_F_u_n_c_t_i_o_n, an error pop-up might appear when no
data exists on an optional port that is referenced in
the Shape script.
+o In _L_a_t_F_u_n_c_t_i_o_n, the Shape script might be incorrectly
interpreted when it is newly read after changing the
script file. With the cursor in the Program file
type-in slot, press <Enter>; this causes _L_a_t_F_u_n_c_t_i_o_n to
reread the script and usually fixes the problem.
+o If the _M_u_l_t_i_S_l_i_c_e module needs to readjust the Offset
widget back into the range of the number of slices on
its input, it does not recompute the slicing places.
You must adjust the Offset value manually to a valid
value for the module to recompute its output.
+o Geometries saved by _W_r_i_t_e_G_e_o_m will not have the shape
hints normally used to view geometry in _R_e_n_d_e_r.
Therefore an Inventor scene graph saved via _W_r_i_t_e_G_e_o_m
and viewed with _i_v_v_i_e_w may not appear identical to the
same geometry viewed in _R_e_n_d_e_r. Add to the saved
geometry the shape hints documented in the man page for
_R_e_n_d_e_r.
- 6 -
4.5 _C_o_n_t_r_o_l__P_a_n_e_l__E_d_i_t_o_r
+o The Control Panel Editor (CPE) does not retain all
information concerning a widget's properties when
switching between widgets. If you change a widget from
a radio button to an option menu, the radio buttons'
labels are not applied to the new option menu. This
occurs also for other widget combinations.
+o Very long labels for Radio Button and Option Menu
widgets can confuse the CPE. In this case, the editor
displays a long label, but the bank of option boxes is
incorrect, obscuring the buttons.
4.6 _M_o_d_u_l_e__B_u_i_l_d_e_r
+o In the Connections panel, you cannot wire to any
lattice in the layers of a pyramid other than the
first.
+o It is too easy to make wiring mistakes in the
Connections panel. In particular, you can wire a (char
*) parameter value in a port to a (char) function
argument, resulting in a compile-time error if you let
the module builder create your function prototype.
+o You cannot set the value of a constant wired to an
output port structure member. Instead, wire the
constant to a function argument and from there to the
output port.
+o Using strings as function parameters is confusing. A
function argument in a C or C++ user function that is
to receive a character string from a parameter port
must be specified (in the Function Args panel) as type
``char'' and reference ``Array.'' In a Fortran user
function, the function argument must be specified as a
``character'' and a ``Scalar.''
+o You can create a user-defined data type that contains
so many members that the menu for it in the Connections
panel is taller than the height of the screen. If this
happens, apply the keyword ``closed'' to nested
structures within the new type; this prevents the
Module Builder from expanding them out in this menu.
- 7 -
4.7 _D_a_t_a_S_c_r_i_b_e
+o DataScribe does not handle tabs well when attempting to
read formatted input. The tab is treated as having a
fixed with (eg, 1 character) instead of padding out to
the next multiple of the tabbing width. If your data
file contains intermingled text, a formatted read is
the only way to skip the text. If this file also
contains tabs, the specified formatting will be
inconsistent with the file as read by Datascribe and a
core dump may ensue. The solution is to replace all
tabs with the correct (variable) number of spaces.
Datascribe will then read the file correctly.
+o Under some circumstances the DataScribe will delete a
glyph's name (and replace it with an empty string) on
reading a DataScribe module. Attempting to perform
wiring or array component selection in the presence of
an empty name may cause the DataScribe to dump core.
+o In some cases using the Array Component glyph (the
cross-hatched green icon in a vector glyph) will cause
DataScribe to dump core.
+o There are several minor annoyances in version 2.2.2 due
to design incompatibilities with Motif 1.2. Things such
as glyphs that appear the wrong size, incorrect window
sizing, etc, are due to this problem. These problems
are typically minor and pose no impediment to correct
usage of the software.
+o You can overlap templates in the DataScribe slightly.
This can occur under special circumstances if you close
and then open a template that is followed by another
open template. If you save the module, clear the
DataScribe, then read in the script again, the overlap
disappears. The overlap is slight and does not impair
use.
+o Templates and glyphs must have unique names. When you
append a template or glyph, you can create a script
with a duplicate name. You must change the new
template or glyph names to avoid collisions with
existing components in the script. The parser can, at
times, fail to detect the duplicate components.
+o The value of the nDim glyph in an output lattice glyph
should not be altered.
+o The response time is slow while editing names for
parameter glyphs because the CPE must be notified of
- 8 -
changes during this processing. You do not need to
enter a carriage return when typing names and values in
the DataScribe; therefore, the CPE must process each
character separately.
+o Glyph names must not include spaces. This can confuse
the parser.
+o In the save pop-up dialog, if you select _O_K without
selecting or entering a filename, no prefix is assigned
and the files are saved with their default suffix only.
+o In the Control Panel Editor, the _C_a_n_c_e_l button does not
cancel widget editing (that is, editing the widget
type, dimension, position), and it reverts back to the
beginning of the editing session. Editing in the CPE
does not have any widget addition or deletion
semantics. You can add and delete parameters only
through the DataScribe, not through the Control Panel
Editor.
+o Drag-and-drop into output templates is unreliable if
the input pane has been hidden. Glyphs can still be
added to the template by selecting the template, then
selecting the desired items in the palette while
holding down the <Alt> key.
4.8 _L_i_b_r_a_r_i_e_s__a_n_d__M_o_d_u_l_e__B_u_i_l_d_i_n_g__E_n_v_i_r_o_n_m_e_n_t
+o Certain modules in Explorer version 2.2 are
incompatible with the dynamic shared objects (DSOs)
_l_i_b_c_x._s_o and _l_i_b_c_x_X._s_o in this release. However, all
such modules are authored by Silicon Graphics, are
included on this release, and are intended to be
installed to replace the previous distribution. See the
previous section "Module Suite" in this chapter for
more details.
+o Linking modules that contain C++ source files gives a
linker warning indicating that the C++ library was not
used and could be removed from the link line. This
happens because the module control wrapper (MCW)
prelinks against the C++ library. No action is
necessary.
+o Explorer modules are not marked for QuickStart by the
loader. You may observe a slightly longer startup time
than would have been possible with a quickstarting
executable.
- 9 -
+o If you create a new data type with two unlabeled
members having the same name at the same scoping depth
from their shared parent types, the wrapper code
generator might try to call an API routine that doesn't
exist, resulting in a module compilation error. The
workaround is to label the members with unique names or
change the member names so that they are unique.
+o Using the Workshop Performance Analyzer tool on
Explorer modules is not currently supported.
+o Modules written in Fortran that happen to call routines
from the Explorer Geometry API (eg, cxGeo* calls) may
exit when run. In these cases there will be no
resulting error message identifying the cause of the
module death. The module exits because a symbol is
undefined, but the situation is further confounded by
an absence of linker (ld) or run-time loader (rld)
error messages identifying the undefined symbol.
Because Fortran modules call an interface routine found
in libcx.so or libcxX.so, which then calls the cxGeo
routine in libgeometry.a, the correct ordering of the
symbols on the link line is one of
userFunc.o -lcx -lgeometry
userFunc.o -lcxX -lgeometry
Because User Library symbols are placed before the
Explorer system libraries on the link line, the actual
order reverses the cx and geometry libraries. This
yields an undefined symbol at run time.
The workaround is simple. Authors of Fortran geometry
modules must place the symbols
-L$(CXLIBDIR) $(LIBAPI)
before $(GEOMETRYLIBS) in the User Libraries field of
the Module Builder main window. Authors of Fortran
geometry modules using X Windows must instead add the
symbols
-L$(CXLIBDIR) $(LIBAPI_X)
For instance, a User Libraries line that read
$(GEOMETRYLIBS) mylib.a
would now read as one of the following two lines,
depending on the absence or presence of X Windows code
- 10 -
in the module:
-L$(CXLIBDIR) $(LIBAPI) $(GEOMETRYLIBS) mylib.a
-L$(CXLIBDIR) $(LIBAPI_X) $(GEOMETRYLIBS) mylib.a